Updated dependencies#316
Conversation
c9161c3 to
f8ed5fb
Compare
ayusharma
left a comment
There was a problem hiding this comment.
Thanks @vladislavarsenev. Left couple of small suggestions, other than that everything looks good to me 🚀 Thank you ❤️ I would approve after the discussion on open questions in PR.
| "engines": { | ||
| "node": ">18.12" | ||
| }, | ||
| "packageManager": "yarn@4.5.1", |
There was a problem hiding this comment.
The packageManager field is in experimental. I would recommend to not to add. https://nodejs.org/docs/latest-v20.x/api/all.html#all_packages_packagemanager
There was a problem hiding this comment.
I've deleted "packageManager" from package.json and removed corepack from CI since packageManager was mandatory thing for using it. However, I would like to notice the fact that although all these features are experimental, they have been around for 4 years.
I should ask you about --experimental-vm-modules which I added for launching tests with the newest prettier version and it was necessary since prettier@3 utilizes dynamic import. I tried quickly transpile code to omit --experimental-vm-modules, but failed. Should I to figure out how to do so without --experimental-vm-modules?
| getAllCommentsFromNodes(nodes).some( | ||
| (comment) => | ||
| comment.loc.start.line === 1 && | ||
| comment.loc?.start.line === 1 && |
There was a problem hiding this comment.
May be 😉
| comment.loc?.start.line === 1 && | |
| comment.loc && comment.loc.start.line === 1 && |
There was a problem hiding this comment.
Fixed, but what a benefit to write in this way? It would never equal 1 if comment.loc was undefined.
byara
left a comment
There was a problem hiding this comment.
I left one comment but it is not a blocker. Thank you so much for taking a look 👍
There was a problem hiding this comment.
Just a suggestion (which I think may unblock other things too) is to maybe unpin most of these dependencies?
What do you think @ayusharma?
Because right now we are using exact versions of certain dependencies. I was wondering if we could move away from this.
There was a problem hiding this comment.
Do you want to use "compatible with version" or "approximately equivalent" modes? What are benefits of these approaches? I'm curious because last 4 or 5 years we used exact versions on all projects and it was more predictable and convenient.
There was a problem hiding this comment.
I think ^ (Compatible with version) is something we want to go for 👍
There was a problem hiding this comment.
Do you know about any limitations of using ^ right now?
There was a problem hiding this comment.
I think there were some issues when people had different version of the same dependencies on their project? 🤔 Or am I missing something @ayusharma

Updated following dependencies:
Updated tools: